The Tableau Workbench

The Tableau Workbench (TWB) is a generic framework for building automated theorem provers for arbitrary propositional logics. The TWB has a small core that defines its general architecture, some extra machinery to specify tableau-based provers and an abstraction language for expressing tableau rules. This language allows users to “cut and paste” tableau rules from textbooks and to specify a search strategy for applying those rules in a systematic manner. A new logic module defined by a user is translated and compiled with the proof engine to produce a specialized theorem prover for that logic. The TWB provides various hooks for implementing blocking techniques using histories and variables, as well as hooks for utilising/defining optimisation techniques like backjumping, simplification and caching. We describe the latest version of the TWB which has changed substantially since our system description in TABLEAU 2003. Introduction and Motivation. Highly optimised provers like MSPASS [HS00] and FaCT [HPS98] can test formulae with hundreds of symbols within a few seconds. Generic logical frameworks like Isabelle [Pau93] allow us to implement almost any logical calculus as a “shallow embedding” with an automatic search tactic. But researchers often find these tools too complex to learn, program or modify. In the middle are the LWB [Heu96], LoTReC [GHLS05] and LeanTAP [BP95] which implement many different logics or which allow users to create their own prover. The LWB provides a large (but fixed) number of logics while LoTReC requires the logic to have a binary relational semantics. If you have just invented a new tableau calculus for a logic without such semantics, then LoTReC and the LWB are not very useful. Lazy logicians, as opposed to real programmers, usually then extend LeanTAP, but there is no generic LeanTAP implementation that contains features like loop-checking or further optimisations. The Tableaux Work Bench (TWB) is a generic framework for building automated theorem provers for arbitrary (propositional) logics. A logic module defined by the user is translated by the TWB into OCaml code, which is compiled with the TWB libraries to produce a tableau prover for that logic. Lazy logicians can encode their rules easily to implement naive provers for their favourite logics without learning OCaml. Real programmers can use the numerous optimisation hooks to produce faster provers and even tailor the system to their own requirements by writing their own OCaml libraries. ⋆ NICTA is funded by the Australian Government’s Dept of Communications, Information Technology and the Arts and the Australian Research Council through Backing Australia’s Ability and the ICT Centre of Excellence program. Programming Language and Style. We wrote the TWB in OCaml because functional languages are more concise than imperative languages, and functional programs are easier to maintain and more resistant to memory management problems and run-time errors [HJ94]. OCaml also has been used to implement other generic theorem provers like Coq, Hol light and NuPrl. To minimise coding errors and reduce maintenance time, the TWB core infrastructure uses a purely functional style. But to avoid some of the ensuing performance penalties, some data structures use imperative style. Currently the TWB runs on Gnu/Linux and MacOsX and has virtually no dependencies on third-party software outside the OCaml compiler, making it easy to install/port to other platforms. Core Algorithm and Architecture. The core algorithm visits a tree generated by using a user-defined strategy to apply a finite collection of user-defined rules to an initial node containing a finite number of user-defined formulae [AG06]. The TWB is organised into four main components which total roughly 4000 lines of OCaml code (loc). The core (464 loc) contains the visit algorithm, all type definitions and the strategy interpreter. The data-type library (664 loc) implements support data structures. The tableau library (818 loc) provides the machinery to implement tableau-based provers. The syntax library (1624 loc) allows a user to define specific logic modules. Finally the command line interface (226 loc) provides a way to compile and execute the logic modules on input formulae. Defining the Calculus for a Logic. A tableau calculus is defined via a logic module like s4.ml in Appendix 1. Due to space limitations, we describe only the features used in Appendix 1 and assume familiarity with the history-based calculus from [HSZ96]. CONNECTIVES: A connective is either a constant or is a triple with an OCaml type constructor (redundant in future releases), a concrete syntax specification with “ ” indicating arity and argument order, and a binding strength “Zero”, “One” or “Two” with “Two” being the weakest. In Appendix 1, the connectives of S4 are defined as usual. HISTORIES and Variables: Variables must begin with a lower-case letter and histories with an upper-case letter. Histories are used to pass information top-down from numerator to denominators and are typically used to implement blocking techniques. Variables are used to pass information bottom-up from already explored sub-trees to parents. The traditional notion of a branch being “Open” or “Closed” is carried from the leaves to the root by a default variable called status. The default value for a data container is an empty instance of that data container. In Appendix 1, the histories DIAS (diamonds) and UBXS (unboxes) are both sets of formulae with the empty set as default value. TABLEAU and RULES: The collection of rules are enclosed within keywords TABLEAU and END. Rules are specified via the RULE and END keywords with principal formulae enclosed in braces. Id: The simplest tableau rule in Appendix 1 has a name Id and a numerator pattern which partitions the current node into three disjoint parts: a formula A; its negation∼ A; and an (unrestricted) container Z. Since any such clash is sufficient to close the branch, we instruct this rule to commit to the first partition that matches by using a separator of at least two “==” symbols. The directives Close or Open or Stop set the value of the default variable status, stopping the visit procedure and triggering backtracking. Thus the Id rule closes the current branch.